eslint-config-prettier
Advanced tools
Turns off all rules that are unnecessary or might conflict with Prettier.
The eslint-config-prettier npm package is used to disable all formatting-related ESLint rules that might conflict with Prettier. This allows developers to use both ESLint and Prettier without having to deal with conflicting formatting rules. It ensures that ESLint focuses on code-quality rules, and Prettier takes care of code formatting.
Disabling conflicting rules
By extending eslint-config-prettier in your ESLint configuration file, you can turn off all rules that are unnecessary or might conflict with Prettier.
{ "extends": ["prettier"] }Integration with other ESLint configs
eslint-config-prettier can be easily integrated with other ESLint configurations like Airbnb by placing it last in the extends array, which ensures that it will override any other formatting rules that might conflict with Prettier.
{ "extends": ["airbnb", "prettier"] }Support for plugins
eslint-config-prettier provides support for disabling conflicting rules from various ESLint plugins, such as React or TypeScript, ensuring compatibility across different codebases.
{ "extends": ["prettier/react", "prettier/@typescript-eslint"] }eslint-config-standard is an ESLint Shareable Config for JavaScript Standard Style. It enforces a consistent style across your codebase. Unlike eslint-config-prettier, it does not turn off formatting rules and is not specifically designed to be used with Prettier.
eslint-config-airbnb is one of the most popular ESLint configurations which enforces Airbnb's JavaScript style guide. It includes a set of rules for code quality and formatting. While it can be used with Prettier, it does not disable formatting rules by default like eslint-config-prettier does.
eslint-config-google is based on Google's JavaScript style guide. It provides a set of ESLint rules that align with Google's code style recommendations. Similar to eslint-config-airbnb, it is not tailored for use with Prettier and does not disable conflicting formatting rules.
Turns off all rules that are unnecessary or might conflict with Prettier.
This lets you use your favorite shareable config without letting its stylistic choices get in the way when using Prettier.
Note that this config only turns rules off, so it only makes sense using it together with some other config.
Install eslint-config-prettier:
npm install --save-dev eslint-config-prettier
Then, add eslint-config-prettier to the "extends" array in your .eslintrc.* file. Make sure to put it last, so it gets the chance to override other configs.
{
"extends": [
"some-other-config-you-use",
"prettier"
]
}
A few ESLint plugins are supported as well:
Add extra exclusions for the plugins you use like so:
{
"extends": [
"some-other-config-you-use",
"prettier",
"prettier/@typescript-eslint",
"prettier/babel",
"prettier/flowtype",
"prettier/react",
"prettier/standard",
"prettier/unicorn",
"prettier/vue"
]
}
If you extend a config which uses a plugin, it is recommended to add "prettier/that-plugin" (if available). For example, eslint-config-airbnb enables eslint-plugin-react rules, so "prettier/react" is needed:
{
"extends": [
"airbnb",
"prettier",
"prettier/react"
]
}
If you’re unsure which plugins are used, you can usually find them in your package.json.
Some of the rules that eslint-config-prettier turns off may be deprecated. This is perfectly fine, but if you really need to omit the deprecated rules, you can do so by setting the ESLINT_CONFIG_PRETTIER_NO_DEPRECATED environment variable to a non-empty value. For example:
env ESLINT_CONFIG_PRETTIER_NO_DEPRECATED=true npx eslint-find-rules --deprecated index.js
eslint-config-prettier also ships with a little CLI tool to help you check if your configuration contains any rules that are unnecessary or conflict with Prettier.
You can run it using npx:
npx eslint --print-config path/to/main.js | npx eslint-config-prettier-check
(Change path/to/main.js to a file that exists in your project.)
In theory you need to run npx eslint --print-config file.js | npx eslint-config-prettier-check for every single file in your project to be 100% sure that there are no conflicting rules, because ESLint supports having different rules for different files. But usually you’ll have about the same rules for all files, so it is enough to run the command on one file (pick one that you won’t be moving). If you use multiple configuration files or overrides, you can (but you probably don’t need to!) run the above script several times with different --print-config arguments, such as:
npx eslint --print-config index.js | npx eslint-config-prettier-check
npx eslint --print-config test/index.js | npx eslint-config-prettier-check
npx eslint --print-config legacy/main.js | npx eslint-config-prettier-check
Exit codes:
There a few rules that eslint-config-prettier disables that actually can be enabled in some cases.
--fix.For maximum ease of use, the special rules are disabled by default. If you want them, you need to explicitly specify them in your ESLint config.
These rules might cause problems if using eslint-plugin-prettier and --fix.
If you use any of these rules together with the prettier/prettier rule from eslint-plugin-prettier, you can in some cases end up with invalid code due to a bug in ESLint’s autofix.
These rules are safe to use if:
eslint --fix and prettier --write as separate steps.--fix. (But then, what’s the point?)You can still use these rules together with eslint-plugin-prettier if you want, because the bug does not occur all the time. But if you do, you need to keep in mind that you might end up with invalid code, where you manually have to insert a missing closing parenthesis to get going again.
If you’re fixing large of amounts of previously unformatted code, consider temporarily disabling the prettier/prettier rule and running eslint --fix and prettier --write separately.
See these issues for more information:
When the autofix bug in ESLint has been fixed, the special case for these rules can be removed.
This rule requires certain options.
If a block (for example after if, else, for or while) contains only one statement, JavaScript allows omitting the curly braces around that statement. This rule enforces if or when those optional curly braces should be omitted.
If you use the "multi-line" or "multi-or-nest" option, the rule can conflict with Prettier.
For example, the "multi-line" option allows this line:
if (cart.items && cart.items[0] && cart.items[0].quantity === 0) updateCart(cart);
However, Prettier might consider the line too long and turn it into the following, which the "multi-line" option does not allow:
if (cart.items && cart.items[0] && cart.items[0].quantity === 0)
updateCart(cart);
If you like this rule, it can be used just fine with Prettier as long as you don’t use the "multi-line" or "multi-or-nest" option.
Example ESLint configuration:
{
"rules": {
"curly": ["error", "all"]
}
}
This rule can be used with certain options.
This rule requires empty lines before and/or after comments. Prettier preserves blank lines, with two exceptions:
By default, ESLint requires a blank line above the comment is this case:
if (result) {
/* comment */
return result;
}
However, Prettier removes the blank line:
if (result) {
/* comment */
return result;
}
If you like this rule, it can be used just fine with Prettier as long as you add some extra configuration to allow comments at the start and end of blocks, objects and arrays.
Example ESLint configuration:
{
"rules": {
"lines-around-comment": [
"error",
{
"beforeBlockComment": true,
"afterBlockComment": true,
"beforeLineComment": true,
"afterLineComment": true,
"allowBlockStart": true,
"allowBlockEnd": true,
"allowObjectStart": true,
"allowObjectEnd": true,
"allowArrayStart": true,
"allowArrayEnd": true
}
]
}
}
(The following applies to vue/max-len as well.)
This rule requires special attention when writing code.
Usually, Prettier takes care of following a maximum line length automatically. However, there are cases where Prettier can’t do anything, such as for long strings, regular expressions and comments. Those need to be split up by a human.
If you’d like to enforce an even stricter maximum line length policy than Prettier can provide automatically, you can enable this rule. Just remember to keep max-len’s options and Prettier’s printWidth option in sync.
Keep in mind that you might have to refactor code slightly if Prettier formats lines in a way that the max-len rule does not approve of.
Example ESLint configuration:
{
"rules": {
"max-len": ["error", {"code": 80, "ignoreUrls": true}]
}
}
This rule requires certain options.
For example, the rule could warn about this line:
var x = a => 1 ? 2 : 3;
With {allowParens: true} (the default since ESLint 6.0.0), adding parentheses is considered a valid way to avoid the arrow confusion:
var x = a => (1 ? 2 : 3);
While Prettier keeps those parentheses, it removes them if the line is long enough to introduce a line break:
EnterpriseCalculator.prototype.calculateImportantNumbers = inputNumber =>
1 ? 2 : 3;
With {allowParens: false}, ESLint instead suggests switching to an explicit return:
var x = a => { return 1 ? 2 : 3; };
That causes no problems with Prettier.
If you like this rule, it can be used just fine with Prettier as long as the allowParens option is off.
Example ESLint configuration:
{
"rules": {
"no-confusing-arrow": ["error", { "allowParens": false }]
}
}
(Note: The CLI helper tool considers {allowParens: true} to be the default, which is the case since ESLint 6.0.0. The tool will produce a warning if you use the default even if you use an older version of ESLint. It doesn’t hurt to explicitly set {allowParens: false} even though it is technically redundant. This way you are prepared for a future ESLint upgrade and the CLI tool can be kept simple.)
This rule requires special attention when writing code.
This rule forbids mixing certain operators, such as && and ||.
For example, the rule could warn about this line:
var foo = a + b * c;
The rule suggests adding parentheses, like this:
var foo = a + (b * c);
However, Prettier removes many “unnecessary” parentheses, turning it back to:
var foo = a + b * c;
If you want to use this rule with Prettier, you need to split the expression into another variable:
var bar = b * c;
var foo = a + bar;
Keep in mind that Prettier prints some “unnecessary” parentheses, though:
var foo = (a && b) || c;
Example ESLint configuration:
{
"rules": {
"no-mixed-operators": "error"
}
}
This rule requires certain Prettier options.
This rule disallows the use of tab characters at all. It can be used just fine with Prettier as long as you don’t configure Prettier to indent using tabs.
Example ESLint configuration:
{
"rules": {
"no-tabs": "error"
}
}
Example Prettier configuration (this is the default, so adding this is not required):
{
"useTabs": false
}
Note: Since ESlint 5.7.0 this rule can be configured to work regardless of your Prettier configuration:
{
"rules": {
"no-tabs": ["error", {"allowIndentationTabs": true}]
}
}
A future version of eslint-config-prettier might check for that automatically.
This rule requires special attention when writing code.
This rule disallows confusing multiline expressions where a newline looks like it is ending a statement, but is not.
For example, the rule could warn about this:
var hello = "world"
[1, 2, 3].forEach(addNumber)
Prettier usually formats this in a way that makes it obvious that a semicolon was missing:
var hello = "world"[(1, 2, 3)].forEach(addNumber);
However, there are cases where Prettier breaks things into several lines such that the no-unexpected-multiline conflicts.
const value = text.trim().split("\n")[position].toLowerCase();
Prettier breaks it up into several lines, though, causing a conflict:
const value = text
.trim()
.split("\n")
[position].toLowerCase();
If you like this rule, it can usually be used with Prettier without problems, but occasionally you might need to either temporarily disable the rule or refactor your code.
const value = text
.trim()
.split("\n")
// eslint-disable-next-line no-unexpected-multiline
[position].toLowerCase();
// Or:
const lines = text.trim().split("\n");
const value = lines[position].toLowerCase();
Note: If you do enable this rule, you have to run ESLint and Prettier as two separate steps (and ESLint first) in order to get any value out of it. Otherwise Prettier might reformat your code in such a way that ESLint never gets a chance to report anything (as seen in the first example).
Example configuration:
{
"rules": {
"no-unexpected-multiline": "error"
}
}
(The following applies to babel/quotes and @typescript-eslint/quotes as well.)
This rule requires certain options and certain Prettier options.
Usually, you don’t need this rule at all. But there are two cases where it could be useful:
If you’d like all strings to use backticks (never quotes), enable the "backtick" option.
Example ESLint configuration:
{
"rules": {
"quotes": ["error", "backtick"]
}
}
In the following example, the first array item could have been written with quotes instead of backticks.
const strings = [
`could have been a regular string`,
`
multiple
lines
`,
`uses ${interpolation}`,
String.raw`\tagged/`,
];
If you’d like ESLint to enforce `could have been a regular string` being written as either "could have been a regular string" or 'could have been a regular string', you need to use some specific configuration. The quotes rule has two options, a string option and an object option.
"single" or "double" and be kept in sync with Prettier’s singleQuote option."avoidEscape": true to follow Prettier’s string formatting rules."allowTemplateLiterals": false to disallow unnecessary backticks.ESLint:
{
"rules": {
"quotes": [
"error",
"double",
{ "avoidEscape": true, "allowTemplateLiterals": false }
]
}
}
Prettier (this is the default, so adding this is not required):
{
"singleQuote": false
}
ESLint:
{
"rules": {
"quotes": [
"error",
"single",
{ "avoidEscape": true, "allowTemplateLiterals": false }
]
}
}
Prettier:
{
"singleQuote": true
}
This rule requires certain options.
This rule enforces whether elements should be self-closing or not.
Prettier generally preserves the way you wrote your elements:
<div />
<div></div>
<MyComponent />
<MyComponent></MyComponent>
<svg><path d="" /></svg>
<svg><path d=""></path></svg>
But for known void HTML elements, Prettier always uses the self-closing style. For example, <img> is turned into <img />.
If you like this rule, it can be used just fine with Prettier as long as you set html.void to "any".
Example ESLint configuration:
{
"rules": {
"vue/html-self-closing": [
"error",
{
"html": {
"void": "any"
}
}
]
}
}
These rules don’t conflict with Prettier, but have some gotchas when used with Prettier.
This rule forbids using JavaScript’s confusing comma operator (sequence expressions). This piece of code is not doing what it looks like:
matrix[4, 7];
Prettier adds parentheses to the above to make it clear that a sequence expression is used:
matrix[(4, 7)];
However, the no-sequences rule allows comma operators if the expression sequence is explicitly wrapped in parentheses. Since Prettier automatically wraps them in parentheses, you might never see any warnings from ESLint about comma operators.
Ending up with an accidental sequence expression can easily happen while refactoring. If you want ESLint to catch such mistakes, it is recommended to forbid sequence expressions entirely using no-restricted-syntax (as mentioned in the no-sequences documentation):
{
"rules": {
"no-restricted-syntax": ["error", "SequenceExpression"]
}
}
If you still need to use the comma operator for some edge case, you can place an // eslint-disable-next-line no-restricted-syntax comment on the line above the expression. no-sequences can safely be disabled if you use the no-restricted-syntax approach.
You can also supply a custom message if you want:
{
"rules": {
"no-restricted-syntax": [
"error",
{
"selector": "SequenceExpression",
"message": "The comma operator is confusing and a common mistake. Don’t use it!"
}
]
}
}
eslint-config-prettier has been tested with:
Have new rules been added since those versions? Have we missed any rules? Is there a plugin you would like to see exclusions for? Open an issue or a pull request!
If you’d like to add support for eslint-plugin-foobar, this is how you’d go about it:
First, create foobar.js:
"use strict";
module.exports = {
rules: {
"foobar/some-rule": "off"
}
};
Then, create test-lint/foobar.js:
/* eslint-disable quotes */
"use strict";
// Prettier does not want spaces before the parentheses, but
// `plugin:foobar/recommended` wants one.
console.log();
test-lint/foobar.js must fail when used with eslint-plugin-foobar and eslint-plugin-prettier at the same time – until "prettier/foobar" is added to the "extends" property of an ESLint config. The file should be formatted according to Prettier, and that formatting should disagree with the plugin.
Finally, you need to mention the plugin in several places:
"foobar.js" to the "files" field in package.json.package.json..eslintrc.base.js.README.md.When you’re done, run npm test to verify that you got it all right. It runs several other npm scripts:
"test:lint" makes sure that the files in test-lint/ pass ESLint when the exclusions from eslint-config-prettier are used. It also lints the code of eslint-config-prettier itself, and checks that Prettier has been run on all files."test:lint-verify-fail" is run by a test in test/lint-verify-fail.test.js."test:lint-rules" is run by a test in test/rules.test.js."test:jest" runs unit tests that check a number of things:
"test:cli-sanity" and "test:cli-sanity-warning" are sanity checks for the CLI.MIT.
Version 6.15.0 (2020-10-27)
FAQs
Turns off all rules that are unnecessary or might conflict with Prettier.
The npm package eslint-config-prettier receives a total of 13,952,161 weekly downloads. As such, eslint-config-prettier popularity was classified as popular.
We found that eslint-config-prettier demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 2 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.